Java operating systems: design and implementation

Journal ArticleLanguage-based extensible systems such as Java use type safety to provide memory safety in a single address space. Memory safety alone, however, is not sufficient to protect different applications from each other. such systems must support a process model that enables the control and management of computational resources. In particular, language-based extensible systems must support resource control mechanisms analogous to those in standard operating-systems. They must support the separation of processes and limit their use of resources, but still support safe and efficient interprocess communication

Nested Java processes: OS structure for mobile code

The majority of work on protection in single-language mobile code environments focuses on information security issues and looks to the language environment for solutions. What is needed in these environments are not ad-hoc or incremental changes but a coherent approach to security, failure isolation, and resource management. Protection, separation, and control of the resources used by mutually untrusting components, applets, applications, or agents are exactly the same problems faced by multi-user operating systems. Therefore, we believe that real solutions will come only if an OS model is rigorously and uniformly applied. We present our initial experience developing a Java-based system which seeks to emulate a highly structured OS based on hardware-enforced protection, Fluke, and provides features appropriate to mobile code

Abstract Nested Java Processes: OS Structure for Mobile Code

The majority of work on protection in single-language mobile code environments focuses on information security issues and depends on the language environment for solutions to the problems of resource management and process isolation. We believe that what is needed in these environments are not ad-hoc or incremental changes but a coherent approach to security, failure isolation, and resource management. Protection, separation, and control of the resources used by mutually untrusting components, applets, applications, or agents are exactly the same problems faced by multi-user operating systems. We believe that real solutions will come only if an OS model is uniformly applied to these environments. We present Alta, our prototype Java-based system patterned on Fluke, a highly structured, hardware-based OS, and report on its features appropriate to mobile code. 1 Operating System Model Required In the last European SIGOPS Workshop, our paper [17] argued that the local operating system is an essential foundation for global applications. We described the many demands that a reasonably well functioning distributed system places on the local OS, and particularly emphasized end-system security in the widespread presence of mobile code. The focus of that paper was on making the case for the importance of the local OS, and outlining an appropriate OS for that environment: the Fluke [10] operating system, an OS based on a recursive virtual machine model, analogous to the Cambridge CAP Computer [30], but implemented by a microkernel instead of special hardware. In this paper we assume that the importance of the loca

Abstract Janos: A Java-oriented OS for Active Network Nodes

Janos is an operating system for active network nodes whose primary focus is strong resource management and control of untrusted active applications written in Java. Janos includes the three major components of a Javabased active network operating system: the low-level NodeOS, a resource-aware Java Virtual Machine, and an active network protocol execution environment. Each of these components is separately usable. This article lays out the Janos design and its rationale.

User-level Checkpointing Through Exportable Kernel State

Checkpointing, process migration, and similar services need to have access not only to the memory of the constituent processes, but also to the complete state of all kernel provided objects (e.g., threads and ports) involved. Traditionally, a major stumbling block in these operations is acquiring and re-creating the state in the operating system. We have implemented a transparent user-mode checkpointer as an application on our Fluke microkernel. This microkernel consistently and cleanly supports the importing and exporting of fundamentalkernel state safely to and from user applications. Implementing a transparent checkpointing facility with this sort of kernel support simplifies the implementation, and expands its flexibility and power. 1. Introduction Checkpointing is a technique for applications to recover from transient failures through rollback recovery. A complete image of the application is created by the checkpointer. The image must contain enough "state" to enable the checkpoi..

Abstract Interface and Execution Models in the Fluke Kernel

We have defined and implemented a kernel API that makes every exported operation fully interruptible and restartable, thereby appearing atomic to the user. To achieve interruptibility, all possible kernel states in which a thread may become blocked for a “long ” time are represented as kernel system calls, without requiring the kernel to retain any unexposable internal state. Since all kernel operations appear atomic, services such as transparent checkpointing and process migration that need access to the complete and consistent state of a process can be implemented by ordinary user-mode processes. Atomic operations also enable applications to provide reliability in a more straightforward manner. This API also allows us to explore novel kernel implementation techniques and to evaluate existing techniques. The Fluke kernel’s single source implements either the “process ” or the “interrupt ” execution model on both uniprocessors and multiprocessors, depending on a configuration option affecting a small amount of code. We report preliminary measurements comparing fully, partially and non-preemptible configurations of both process and interrupt model implementations. We find that the interrupt model has a modest performance advantage in some benchmarks, maximum preemption latency varies nearly three orders of magnitude, average preemption latency varies by a factor of six, and memory use favors the interrupt model as expected, but not by a large amount. We find that the overhead for restarting the most costly kernel operation ranges from 2–8 % of the cost of the operation.